Efficient header handling involving GSM/EDGE radio access networks

ABSTRACT

To facilitate handing of headers for Internet-transmissible packets, a radio access network sends to a mobile station (MS) a message which downloads configuration options for each of corresponding plural header adaptation strategies. The mobile station (MS) elects one of the plural header adaptation strategies and includes the elected strategy in a return message, whereby the radio access network configures a radio bearer for packets to be transmitted between the radio access network and the mobile station. In a first illustrated mode of implementation of the invention, the radio access network is a GSM/EDGE radio access network, with the downloading message being a radio bearer setup message and the return message sent from the mobile station to the radio access network being a radio bearer setup complete message. In a second illustrated mode of implementation of the invention, the message that downloads configuration options for each of plural header adaptation strategies is a handover command message for handing over control of the mobile station from a source radio access network to a target radio access network. In this second mode, the message which informs which of the plural strategies is elected is a handover complete message. The plural header adaptation strategies can include header compression (useful, e.g., for a multimedia service); header removal (useful, e.g., for a spectrum efficient voice packet voice bearer that reuses codec-specific channel coding); and no header adaptation.

BACKGROUND

[0001] 1. Field of the Invention

[0002] The present invention pertains to wireless telecommunications,and particularly to the handling of headers for Internet-transmissiblepackets in a radio access network having varied header handlingcapability.

[0003] 2. Related Art and Other Considerations

[0004] In a typical cellular radio system, mobile stations (MSs)communicate via a radio access network (RAN) to one or more corenetworks. The mobile stations can be mobile terminals such as mobiletelephones (“cellular” telephones) and laptops with mobile termination,and thus can be, for example, portable, pocket, hand-held,computer-included, or car-mounted mobile devices which communicate voiceand/or data with radio access network.

[0005] The radio access network (RAN) covers a geographical area whichis divided into cell areas, with each cell area being served by a basestation. A cell is a geographical area where radio coverage is providedby the radio base station equipment at a base station site. Each cell isidentified by a unique identity, which is broadcast in the cell. Thebase stations communicate over the air interface (e.g., radiofrequencies) with the mobile stations within range of the base stations.In the radio access network, several base stations are typicallyconnected (e.g., by landlines or microwave) to a base station controller(BSC) which supervises and coordinates various activities of the pluralbase stations connected thereto.

[0006] Two examples of a radio access network is Global System forMobile Communications (GSM) developed in Europe and its third generationevolution GSM/EDGE Radio Access Netowrk (GERAN). Another example radioaccess network (which is also an evolution of GSM) is the UniversalMobile Telecommunications System (UMTS) Terrestrial Radio Access Network(UTRAN). UTRAN of UMTS is essentially a wideband code division multipleaccess (W-CDMA) system.

[0007] According to the basic architecture for the third generationradio access networks (RANs) is a master/slave relationship between theRAN and the mobile station. The mobile station is able to indicate itscapabilities to the RAN. Based on the service that is requested by themobile station (MS) and the capabilities of the mobile station (MS), theRAN makes a configuration choice and signals this configuration to themobile station (MS) over the radio interface using radio resourcecontrol (RRC) signaling. The configuration must then be supported by themobile station (MS). If the MS cannot support the configuration, afailure must be sent.

[0008] Some radio access networks, particularly including the GERAN(GSM/EDGE Radio Access Network), accommodate both circuit switched andpacket switched connections. Many types of packet switched connections,including some of those which provide speech service, utilize internetprotocol (IP).

[0009] A significant challenge in running a service based on internetprotocol (IP) is the considerably large overhead (e.g., aggregateheaders) of a packet in relation to the payload. FIG. 7A illustrates anexample generalized internet protocol (IP) packet; FIG. 7B illustratesan example internet protocol (IP) packet for speech comprising aRTP/UDP/IP header and speech payload. The RTP/UDP/IP header header ofFIG. 7B typically begins with either an IPv4 or IPv6 field (twenty orforty octets, respectively), and also includes a UDP field (eightoctets), and an RTP header (twelve octets). In either the IPv4 or IPv6scenario, the RTP/UDP/IP header has a greater length than the thirty-twooctet speech payload of the internet protocol (IP) packet. Regarding RTPand UDP in general, see RTP: A Transport Protocol for Real-TimeApplications, RFC 1889; and J. Postel, User Diagram Protocol, RFC 761,September 1980, both of which are incorporated herein in their entirety.

[0010] Because of the large inefficiency illustrated by FIG. 7A and FIG.7B, various header compression (HC) schemes have been developed toensure that the impact of the overhead (e.g., RTP/UDP/IP header size) onthe efficiency spectrum is reduced. Various examples of headercompression are found in the literature and certain industryspecifications and standards, examples of which are listed below.

[0011] The internet engineering task force (IETF) is the standardizationbody which carries out development and standardization for protocols tobe employed in the internet. The following header adaptation protocolshave been specified in the IETF (all of which are incorporated herein byreference in their entirety):

[0012] S. Casner, V. Jacobson, “Compressing IP/UDP/RTP Headers forLow-Speed Serial Links”, RFC 2508, February 1999.

[0013] Mikael Degermark, Bjorn Nordgren, Stephen Pink, “IP HeaderCompression”, RFC 2507, February 1999.

[0014] M. Engan, S. Casner, C. Bormann, “IP Header Compression overPPP”, RFC 2509, February 1999.

[0015] V. Jacobson, “Compressing TCP/IP Headers for Low-Speed SerialLinks”, RFC 1144, February 1990.

[0016] RFC 3095 Robust Header Compression (ROHC): Framework and FourProfiles: RTP, UDP, ESP, and Uncompressed.

[0017] RFC 3096 Requirements For Robust IP/UDP/RTP Header Compression.

[0018] For GERAN (GSM/EDGE Radio Access Network), an optimized voicebearer is currently being standardized which would provide a spectrumefficient way of transporting voice internet protocol packetsoriginating in the Iu Interface (between the UTRAN and a core network)This spectrum efficiency is achieved by reusing the codec-specificchannel coding from GSM over the air interface. To conform to thepayload format of this channel coding, a procedure know as headerremoval (HR) is performed to remove the RTP/UDP/IP header beforetransporting the packets over the air interface. The RTP/IUDP/IP headermay then generated after the air-interface. The standardization of theheader removal algorithm to be employed by GERAN is under theresponsibility of the Technical Specification Group GSM/EDGE RadioAccess Network (TSG GERAN) group within the 3^(rd) GenerationPartnership Project (3GPP).

[0019] There are, however, other types of speech service potentiallyavailable in GERAN (GSM/EDGE Radio Access Network). For example, ageneral multimedia (MM) bearer with true multimedia (MM) capabilitiesand transparent IP connectivity is envisioned. See, e.g., 3GPP TS23.228, V5.0.0 (2001-04), 3^(rd) Generation Partnership Project:Technical Specification Group Services and System Aspects; IP Multimedia(IM) Subsystem - Stage 2 (Release 5); and 3GPP TS 23.002, V5.0.0(2000-12), 3^(rd) Generation Partnership Project: TechnicalSpecification Group Services and System Aspects; Network Architecture(Release 5). This general IP multimedia (MM) bearer is to providetransparent IP connectivity and enable sessions where speech is but oneof the possible media types (other possible media types are video,shared white-board, streaming, etc.). Transparency in this context meansthat the IP headers arrive unchanged at the end terminal (this cannot beguaranteed by the header removal scheme employed on the optimized voicebearer). Transparency is a prerequisite for providing synchronizationbetween different media. The multimedia (MM) bearer can utilize headercompression (such as one of the compression techniques discussed above),or alternatively have no header adaptation mechanism in order tofacilitate this transparency.

[0020] While GERAN supports header compression protocols such as variousones listed above, the strategy proposed for optimized speech in GERANto date involves utilization of header removal for the reasons abovementioned. Header removal strips the internet protocol (IP) headers andtransmits only the payload. However, at least initially in headerremoval, state information may be exchanged between peer entities toensure that regeneration of the internet protocol (IP) headers ispossible.

[0021] The above-mentioned Iu Interface is an open standardizedinterface that can be used for many different radio access networks(RANs). Currently, the Iu Interface is used for the UMTS Terrestrial RAN(UTRAN), as described (for example) in 3GPP TS 25.413. The Iu Interfacecan now also be used for GERAN (GSM/EDGE Radio Access Network). Sincethe Iu Interface is an open interface, it would extremely undesirable tomodify the set of possible radio access bearer (RAB) attributes andvalue ranges involved with the Iu Interface for the purpose ofconfiguring GERAN specific parameters. In fact, modifying the possibleradio access bearer (RAB) attributes and value ranges would change theexisting quality of service concept for all radio access networks thatuse the Iu Interface.

[0022] What is needed, therefore, and an object of the presentinvention, is a technique for correctly configuring radio bearers forappropriate RTP/UDP/IP header optimization or adaptation schemes in anefficient way within existing network architectural concepts.

BRIEF SUMMARY OF THE INVENTION

[0023] To facilitate handing of headers for Internet-transmissiblepackets, a radio access network sends to a mobile station (MS) a messagewhich downloads configuration options for each of corresponding pluralheader adaptation strategies. The mobile station (MS) elects one of theplural header adaptation strategies and includes the elected strategy ina return message, whereby the radio access network configures a radiobearer for packets to be transmitted between the radio access networkand the mobile station.

[0024] In a first illustrated mode of implementation of the invention,the radio access network is a GSM/EDGE radio access network. Thedownloading message sent from the radio access network and the returnmessage are both radio resource control (RRC) messages. In particular,the downloading message is a radio bearer setup message and the returnmessage sent from the mobile station to the radio access network is aradio bearer setup complete message.

[0025] In a second illustrated mode of implementation of the invention,the message that downloads configuration options for each of pluralheader adaptation strategies is a handover command message for handingover control of the mobile station from a source radio access network toa target radio access network. In this second mode, the message whichinforms which of the plural strategies is elected is a handover completemessage. In this second mode, the target radio access network generatesthe configuration options for each of the plural header adaptationstrategies and sends the configuration options from the target radioaccess network to a source radio access network. The source radio accessnetwork then sends the configuration options from the source radioaccess network to the mobile station. In the illustrated implementation,one of the target radio access network and the source radio accessnetwork is a GSM/EDGE (GERAN) radio access network and another of thetarget radio access network and the source radio access network is aUTRAN (Universal Mobile Telecommunications radio access network).

[0026] The plural header adaptation strategies included in thedownloading radio resource control (RRC) message can include headercompression (useful, e.g., for a multimedia service); header removal(useful, e.g., for a spectrum efficient packet voice bearer that reusescodec-specific channel coding); and no header adaptation.

BRIEF DESCRIPTION OF THE DRAWINGS

[0027] The foregoing and other objects, features, and advantages of theinvention will be apparent from the following more particulardescription of preferred embodiments as illustrated in the accompanyingdrawings in which reference characters refer to the same partsthroughout the various views. The drawings are not necessarily to scale,emphasis instead being placed upon illustrating the principles of theinvention.

[0028]FIG. 1 is diagrammatic view of example telecommunications systemin which the present invention may be advantageously employed.

[0029]FIG. 2 is a simplified function block diagram of a portion of aGSM/EDGE Radio Access Network, including a mobile station (MS); a basestation controller (BSC); and a base station (BS).

[0030]FIG. 3 is a diagram showing various events involved in setting upa packet switch internet protocol (IP) voice service according to afirst mode of the present invention.

[0031]FIG. 4A is a diagrammatic view of an example radio bearer setupmessage according to an embodiment of the invention.

[0032]FIG. 4B is a diagrammatic view of an example radio bearer setupcomplete message according to an embodiment of the invention.

[0033]FIG. 5 is diagrammatic view of example telecommunications systemin which the present invention may be advantageously employed inaccordance with a second mode of the invention.

[0034]FIG. 6 is a diagrammatic view showing a relationship between FIG.6A and FIG. 6B.

[0035]FIG. 6A and FIG. 6B are diagrammatic views showing various eventsinvolved in an inter-radio access network handover and thus a secondexample mode of the present invention.

[0036]FIG. 7A is a diagrammatic view of a generalized Internet Protocol(IP) packet showing basic contents and size of a typical payload sizeand the related protocol overhead.

[0037]FIG. 7B is a diagrammatic view of an RTP/UDP/IP speech packetshowing basic contents and size of a typical payload size and therelated protocol overhead.

DETAILED DESCRIPTION OF THE DRAWINGS

[0038] In the following description, for purposes of explanation and notlimitation, specific details are set forth such as particulararchitectures, interfaces, techniques, etc. in order to provide athorough understanding of the present invention. However, it will beapparent to those skilled in the art that the present invention may bepracticed in other embodiments that depart from these specific details.In other instances, detailed descriptions of well-known devices,circuits, and methods are omitted so as not to obscure the descriptionof the present invention with unnecessary detail. Moreover, individualfunction blocks are shown in some of the figures. Those skilled in theart will appreciate that the functions may be implemented usingindividual hardware circuits, using software functioning in conjunctionwith a suitably programmed digital microprocessor or general purposecomputer, using an application specific integrated circuit (ASIC),and/or using one or more digital signal processors (DSPs).

[0039]FIG. 1 shows a telecommunications system 10 operating inconjunction with both a first radio access network 12 having a firsttype radio access technology and a second radio access network 14 havinga second type radio access technology. In the non-limiting example shownin FIG. 1, the first radio access network 12 uses GSM/EDGE radio accesstechnology (GERAN), while the second radio access network 14 uses UTRANradio access technology. Both first radio access network 12 and secondradio access network 14 are connected to an external core network 16,such may be (for example) the Public Switched Telephone Network (PSTN)and/or the Integrated Services Digital Network (ISDN).

[0040] The core network 16 can connect to the first radio access network12 (e.g., the GERAN) over either an interface known as the A interface,an interface known as the Gb interface, or the above mentioned open Iuinterface, or any combination of these three interfaces. In FIG. 1, itis assumed that the first radio access network is only connected overthe Iu interface. The first radio access network 12 includes one or morebase station controllers (BSCs) 26, with each base station controller(BSC) 26 controlling one or more base stations (BTSs) 28. In the exampleshown in FIG. 1, base station controller (BSC) 26 ₁ is connected acrossthe Abis interface to two base stations, particularly base station (BTS)28 ₁₋₁ and base station (BTS) 28 ₁₋₂. Each base station (BTS) 28 ₁ isdepicted in FIG. 1 as serving three cells C. Each cell C is representedby a circle proximate the respective base station. Thus, it will beappreciated by those skilled in the art that a base station may servefor communicating across the air interface for more than one cell, andthat differing base stations may serve differing numbers of cells.

[0041]FIG. 1 also shows that the GERAN typically comprises plural basestation controllers (BSCs) 26, although only two of such base stationcontrollers, particularly base station controllers (BSCs) 26 ₁ and 26 ₂,are illustrated. For simplicity, details of the base station subsystem(BSS) involving base station controller (BSC) 26 ₂ are omitted, it beingunderstood that, like the base station subsystem of base stationcontroller (BSC) 26 ₁, the base station subsystem of base stationcontroller (BSC) 26 ₂ also has its base stations. The base stationcontrollers 26 control radio resources and radio connectivity within aset of cells. Each base station (BTS) 28 handles the radio transmissionand reception within one or more cells.

[0042] The core network 16 also connects to the second radio accessnetwork 14 (e.g., the UTRAN radio access network) over an interface knowas the Iu interface. The second radio access network 14 includes one ormore radio network controllers (RNCs) 26 _(U). For sake of simplicity,the UTRAN 14 of FIG. 1 is shown with only one RNC node. Although notexpressly depicted as such in FIG. 1, the RNC node ²⁶ _(U) is connectedto a plurality of base stations (e.g., node Bs). In second radio accessnetwork (UTRAN network) 14, the radio network controller (RNC) 26 _(U)controls radio resources and radio connectivity within a set of cells,while the base stations handle the radio transmission and receptionwithin one or more cells.

[0043] The Abis interface, a radio interface Um, the Iu interface, andthe other interfaces are shown by dash-dotted lines in FIG. 1 and FIG.2.

[0044]FIG. 2 shows selected general aspects of mobile station (MS) 30and selected functionalities of nodes such as base station controller(BSC) 26 and base station (BS) 28. The mobile station (MS) 30 shown inFIG. 2 includes a data processing and control unit 31 for controllingvarious operations required by the mobile terminal (MT). The dataprocessing and control unit 31 of mobile terminal (MT) 30 includes radiobearer election logic 100, the purpose of which is described in moredetail subsequently. In addition, the data processing and control unit31 provides control signals as well as data to a radio transceiver 33connected to an antenna 35.

[0045] The example base station (BTS) 28 shown in FIG. 2 includes a basestation data processing and control unit 36, which is connected to oneor more base station transceivers (TX/RX) 38. Each base stationtransceiver (TX/RX) 38 is connected to a corresponding antenna 39 whichcommunicates over air interface Um with mobile station (MS) 30.

[0046] The example base station controller (BSC) 26 shown in FIG. 2includes a BSC data processing and control unit 37. The BSC dataprocessing and control unit 37 includes radio resource control logic104. It should be understood by the person skilled in the art that anyor all of radio bearer election logic 100 and radio resource controllogic 104 may be implemented using individual hardware circuits, usingsoftware functioning in conjunction with a suitably programmed digitalmicroprocessor or general purpose computer, using an applicationspecific integrated circuit (ASIC), and/or using one or more digitalsignal processors (DSPs)

[0047] The present invention pertains to the handing of protocoloverhead, e.g., headers, for internet-transmitted packets. In thisregard, the present invention concerns a method of operating a radioaccess network to achieve the desired handling of the headers; a node ofthe radio access network, and a mobile station which cooperates with theradio access network in the handling of the headers. As employed herein“header” and “header adaptation” refers to the protocol overhead forinternet-transmissible or internet-transmitted packets.Internet-transmissible or internet-transmitted packets/services aregenerally based on the Internet Protocol (IP) [see, RFC 791, InternetProtocol, September 1981]. Examples of such internet-transmissible orinternet-transmitted packets/services encompass both speechpackets/services and other packets/services (e.g., non-speech ornon-voice packets/services). While the embodiments and modessubsequently illustrated herein predominately concern RTP/UDP/IP speechpackets which have RTP/UDP/IP headers as protocol overhead, it should beunderstood that the present invention is not limited to RTP/UDP/IPspeech packets nor even to speech packets generally.

[0048] In a first illustrated mode of implementation of the invention,the radio access network is a GSM/EDGE radio access network. Thedownloading message sent from the radio access network and the returnmessage are both radio resource control (RRC) messages. In particular,the downloading message is a radio bearer setup message and the returnmessage sent from the mobile station to the radio access network is aradio bearer setup complete message. FIG. 3 shows various eventsinvolved in setting up a packet switch internet protocol (IP) voiceservice between the mobile station (MS) and GERAN for one exampleimplementation of the first mode of the present invention.

[0049] Event 3-1 represents establishment of a radio resource control(RRC) connection. Subsumed in event 3-1 is the mobile station (MS) 30sending a request that a radio resource control (RRC) connection beestablished; the GERAN responding with a message to the mobile station(MS) 30 for setting up the RRC connection; and, the mobile station (MS)30 replying with a confirmation that the RRC connection setup issuccessful. This confirmation is also known as a “RRC Connection SetupComplete” message. In the “RRC Connection Setup Complete” message,mobile station (MS) 30 indicates to the radio access network whichheader adaptation mechanisms it supports.

[0050] In a more detailed implementation of the first mode, variousmessages are structured to have multiple layers of information elements.In this detailed implementation, information elements can have ahierarchial structure. For example, the “RRC Connection Setup Complete”message just mentioned can include plural information elements such asthose listed in Table 6. Noteable among the information elements of the“RRC Connection Setup Complete” message is a first layer informationelement entitled “UE radio access capability”. Second layer informationelements comprising the information element “UE radio access capability”are listed and described in Table 7, and particularly include theinformation element “PDCP capability”. Third layer information elementscomprising the information element “PDCP capability” are listed anddescribed in Table 8, and particularly include the information elements“Support for Header Removal” and “Support for RFC3095”. Thus, in thismore detailed implementation, the information elements “Support forHeader Removal” and “Support for RFC3095” indicate which headeradaptation mechanisms are supported by mobile station (MS) 30.

[0051] Event 3-2 involves service setup, and includes direct transfermessages (sent from mobile station (MS) 30 to the core network 16)carrying higher layer messages that set up the service with the corenetwork 16. Part of the service setup of event 3-2 IS A PDP contextsetup. During the PDP context setup the mobile station (MS) 30communicates the quality of service (QoS) profile, which is a requestfor a certain quality of service which the core network 16 shouldattempt to provide.

[0052] Assuming that the core network 16 has sufficient resources toestablish the service requested in event 3-2, as event 3-3 a radioaccess bearer(s) [RAB(s)] is established for use by the service. Event3-4 of FIG. 3 shows core network 16 communicating assignment of theRAB(s) to the GERAN 12. The radio access bearer (RAB) contains a certainset of attributes that determine the characteristics of the RAB. Themapping between the QoS profile and the RAB attributes has beenperformed in the core network 16.

[0053] After the RAB assignment of event 3-4 is received at GERAN 12,and particularly at base station controller (BSC) node 26, as event 3-5GERAN 12 reserves the appropriate radio resources required by the RABassignment. Further, as event 3-6, GERAN 12 determines suitableconfiguration options for each of corresponding plural header adaptationstrategies. For example, as event 3-6 GERAN 12 can prepare a firstconfiguration option which includes or pertains to a header compressionstrategy; a second configuration option which includes or pertains to aheader removal strategy; and, a third configuration option whichaccommodates a strategy of no header adaptation. The options prepared byGERAN 12 as event 3-6 can, in the illustrated embodiment, be preparedprimarily or partially by radio resource control logic 104.

[0054] As event 3-7 the base station controller (BSC) node 26 of GERAN12 sends a radio bearer setup message to mobile station (MS) 30. In theillustrated embodiment, the radio bearer setup message of event 3-7 issent on the PDTCH or main DCCH logical channel, but the invention is notlimited to a particular logical channel. The radio bearer setup messageof event 3-7 includes each of the plural configuration options whichwere determined at event 3-6 as being possible for the RAB assignment.

[0055] In the above regard, FIG. 4A illustrates an example format ofportions of a radio bearer setup message germane to the presentinvention. FIG. 4A assumes that the radio bearer setup message includesa header (e.g., shown by the broken line portion 4A-1), and furtherillustrates as 4A-2 various radio bearer setup information elements. Theradio bearer setup information depicted as 4A-2 includes threeconfiguration option information elements (IEs), particularlyinformation element(s) 4A-3 through information element(s) 4A-5. Theinformation element(s) depicted as 4A-3 can be used for possibleimplementation of the first configuration option, e.g., the headercompression strategy for the multimedia bearer. The second configurationoption information element(s) depicted as 4A-4 can be used for possibleimplementation of the header removal strategy for the optimized speechbearer. The third configuration option information element(s) depictedas 4A-5 can be used for possible implementation the of strategy havingno header adaptation.

[0056] Briefly mentioned above in conjunction with event 3-1 was a moredetailed implementation of the first mode having multiple hierarchiallayers of information elements. In an example of this detailedimplementation, the radio bearer setup message has a first layer ofinformation elements, examples of which are listed and described inTable 1. Among the first layer of information elements is an informationelement entitled “RAB information for setup”. The information elemententitled “RAB information for setup” comprise a second layer ofinformation elements which are listed and described in Table 2. Notableamong these second layer information elements is the information elemententitled “RB information to setup”. The information elements comprisingthe information element entitled “RB information to setup” form a thirdlayer of information elements which are listed and described in Table 3.One of the these third layer information elements is the informationelement entitled “PDCP info”. The information elements comprising theinformation element entitled “PDCP info” form a fourth layer ofinformation elements which are listed and described in Table 4. Includedas fourth layer information elements comprising the “PDCP info” are thefollowing information elements: “Header Adaption information”; “HeaderRemoval supported”; “Header Removal Specific parameters”; and “RFC3095supported”.

[0057] Concerning the above-mentioned information elements of Table 4,the “Header Removal supported” and “Header Removal Specific parameters”information elements generally correspond to second configuration optioninformation element(s) depicted as 4A-4 of FIG. 4A, while the “RFC3095supported” information element generally corresponds to the firstconfiguration option, e.g., the header compression option informationelement(s) depicted as 4A-3 of FIG. 4A.

[0058] Concerning the “Header Removal Specific parameters” mentionedabove, depending on the characteristics of the header removal algorithmdefined in TSG GERAN, real time protocol (RTP) (such as time stamps andsequence numbers) may also be included in this information element.

[0059] Specific parameters included in the one or more information itemsof set 4A-4 (for header compression) are essentially the same as thoselisted in 3GPP TS 25.331, V4.0.0, Radio Resource Control Protocol, i.e.,the IETF protocols, RFC 2507 and RFC 3095. Currently the only protocolplanned for support protocols in GERAN is the protocol RFC 3095.

[0060] If the radio access network determines, e.g., on the basis of theof the establish RRC connection messages (and particularly the “RRCConnection Setup Complete” message) of event 3-1 that the radio accessnetwork does not support any of the header adaptation techniques whichare supported by mobile station (MS) 30, the radio access network has toset up or configure a radio bearer with no header adaptation. Setup ofsuch a radio bearer with no header adaptation is indicated in the radiobearer setup message of event 3-7 by the information element “HeaderAdaption information” (an information element listed in the “PDCP info”of Table 4) being set to “NOT”. Therefore, the “Header Adaptioninformation” being set to “NOT” generally corresponds to the thirdconfiguration option, e.g., the no header adaptation option informationelement(s) depicted as 4A-5 of FIG. 4A.

[0061] Thus, from the foregoing it is evident that the radio accessnetwork can structure or format the radio bearer setup message accordingto any of the following alternatives: (1) including only informationelements for the optimized speech bearer; (2) including only informationelements for the IP multimedia bearer; (3) including the informationelements listed for the optimized speech bearer and the informationelements listed for the IP multimedia bearer if mobile station (MS) 30is allowed to choose the radio bearer to be set up; or (4) providing noheader adaptation.

[0062] Upon receipt of the radio bearer setup message, as event 3-8 themobile station (MS) 30 uses its own logic and discretion to elect one ofthe radio bearers listed in the radio bearer setup message, and thus oneof the header adaptation strategies provided by the radio bearer setupmessage. In the illustrated embodiment, radio bearer election logic 100of mobile station (MS) 30 can perform the election of event 3-8. It isthe mobile station (MS) 30 which has complete knowledge of all theservice requirements, e.g., the codec type needed and whether headerremoval or header compression are appropriate. After the election, themobile station (MS) 30 communicates the elected radio bearer, and thusthe header adaptation strategy, in a radio bearer setup complete messagewhich is transmitted to the GERAN 12 as depicted by event 3-9 in FIG. 3.

[0063]FIG. 4B illustrates an example format of portions of a radiobearer setup complete message, including a header 4B-1 and a set of oneor more information items or elements 4B-2 which specify which radiobearer, and hence which header adaptation strategy, was elected and thusis to be used: the optimized voice bearer (with its header removalstrategy), the multimedia bearer (with its header compression), or noheader adaptation. The set of information elements 4B-2 implicitlyaccepts the parameters suggested by the radio access network in theradio bearer setup message. In case the optimized voice bearer is to besetup, the mobile station (MS) 30 may also indicate by an informationitem/element 4B-3 in the radio bearer setup complete message which codectype is to be utilized. In view of the fact that the codec typeinformation item 4B-3 is only for the case of the optimized voicebearer, information item is shown by broken lines in FIG. 4B.

[0064] The type of codec to be used ordinarily will have been negotiatedpreviously by session initiation protocol SIP, but needs to becommunicated to GERAN in order for GERAN to apply the correct channelcoding. Regarding SIP, see M. Handley, H. Schulzrinne, E. Schooler andJ. Rosenberg, SIP: Session Initiation Protocol, RFC 2543, August 2000;and M. Handley and V. Jacobson, SDP: Session Description Protocol, RTC2327, April 1998, both of which are incorporated by reference in theirentirety. To date, the following codec types will have to be supportedon an optimized voice bearer: half rate (HR), full rate (FR), enhancefull rate (EFR), and adaptive multirate (AMR)

[0065] Again referring to the more detailed implementation firstmentioned above in conjunction with event 3-1 (with its multiplehierarchial layers of information elements), in one example of thisdetailed implementation the radio bearer setup complete message of thepresent invention has the information elements listed and described inTable 5. Included as one of the information elements in Table 5 is theinformation element “Header Adaption Info”. The mobile station (MS) 30can indicate that the strategy of no header adaptation is to be utilizedby not including the information element “Header Adaption Info” in theradio bearer setup complete message. Alternatively, the mobile station(MS) 30 can set the information element “Header Removal” to indicatethat the header removal strategy associated with the optimized voicebearer is to be utilized. In this case, information such as the sourceand destination IP addresses and UDP port numbers could be included inthis message if they have not been conveyed to the RAN by other means.Also, the codec to be used will be included in this information element.Alternatively, the mobile station (MS) 30 can set the informationelement “RFC 3095” to indicate that the header compression strategyassociated with multimedia bearer is to be utilized.

[0066] Event 3-10 of FIG. 3 shows GERAN 12 implementing the electedheader adaptation strategy.

[0067] In the event that mobile station (MS) 30 is unable to setup theradio bearer, instead of the radio bearer setup complete message themobile station (MS) 30 returns a radio bearer setup failure message(indicated by the broken line of event 3-11 of FIG. 3).

[0068] In a second illustrated mode of implementation of the invention,the message that downloads configuration options for each of pluralheader adaptation strategies is a handover command message for handingover control of the mobile station (e.g., all the connections with whichthe mobile station is involved) from a source radio access network to atarget radio access network. In this second mode, the message whichinforms which of the plural strategies is elected is a handover completemessage. In this second mode, the target radio access network generatesthe configuration options for each of the plural header adaptationstrategies and sends the configuration options from the target radioaccess network to a source radio access network. The source radio accessnetwork then sends the configuration options from the source radioaccess network to the mobile station. In the illustrated implementation,the target radio access network is a GSM/EDGE (GERAN) radio accessnetwork and the source radio access network is a UTRAN (Universal MobileTelecommunications radio access network).

[0069]FIG. 5 shows more details of the example telecommunicationssystem, particularly for illustrating the second mode of the invention.FIG. 5 shows that gateway general packet radio service (GPRS) supportnode (GGSN) 520 is connected to one or more data networks, such as theInternet, as represented by cloud 522. GGSN 520 communicates over a Gninterface with one or more serving general packet radio service supportnodes (SGSN), of which two representative SGSNs are shown as 524 ₁ and524 ₂. The SGSN 524 ₁ communicates, e.g., with mobile switching center(MSC) node 528 ₁ over a Gs interface; and over an Iu interface with basestation system (BSS) 530 ₁ of a first of two radio access networks,i.e., GERAN 12. The base station system (BSS) 530 ₁ of GERAN 12comprises one or more base station controllers 26, controlling pluralbase stations (BSs) 28, in the manner illustrated in FIG. 1. A secondSGSN 524 ₂ is connected to GGSN 520, and further communicates, e.g.,over an Iu interface with radio network subsystem (RNS) 530 ₂ of asecond of two radio access networks, i.e., UTRAN 14. The radio accesssystem (RNS) 530 ₂ of UTRAN 14 comprises one or more base stationcontrollers 26 _(U), controlling plural base stations (Node Bs) ²⁸ _(U),as understood from FIG. 1. Further details of a Serving GPRS SupportNode (SGSN), and various aspects of operation thereof included packetdata protocol (PDP) context, are described in U.S. Pat. No. 6,104,929,entitled “Data Packet Radio Service With Enhanced Mobility Management”,which is incorporated herein by reference in its entirety.

[0070]FIG. 6, which comprises both FIG. 6A and FIG. 6B, shows variousevents involved in a handover of a mobile from a source radio accessnetwork (e.g., UTRAN 14) to a target radio access network (e.g., GERAN12). While the illustrated handover occurs from UTRAN 14 to GERAN 12, itshould be understood that the present invention is not limited to thistype of handover, and that a handover from GERAN 12 to UTRAN 14 is alsowithin the ambit of the present invention, and that the presentinvention also covers other types of handovers involving yet other typesof radio access networks.

[0071] Event 6-1 depicts mobile station (MS) 30 supplying qualitymeasurements (e.g., signal quality measurements) to the Source RAN(e.g., UTRAN 14). Based on the measurements reported as event 6-1, theSource RAN decides to carry out a handover to the target RAN. In view ofthis handover decision, a transparent container is transported from theSource RAN to the target RAN, as reflected by events 6-2 through 6-4 ofFIG. 6. This transparent container includes information about RRCprotocol context and possibly header compression state information.

[0072] As event 6-5, the target RAN allocates resources for the incomingcall by setting up a radio access bearer (RAB). Then, as events 6-6through 6-8, the target RAN sends back to Source RAN a transparentcontainer which includes all radio related information which mobilestation (MS) 30 requires for an inter-RAN handover, including RRCprotocol context and the configuration options such as those previouslydiscussed with regard to the first mode. The event 6-6 shows thecontainer with its configuration options being sent from the target RANto the new SGSN (e.g., SGSN 524 ₁ in FIG. 5) in a relocation requestacknowledge message; event 6-7 shows the container with itsconfiguration options being sent in a forward relocation responsemessage 6-7 from the new SGSN to the old SGSN (e.g., SGSN 514 ₂ in FIG.5); and event 6-8 shows the container with its configuration optionsbeing sent in a relocation command message from the old SGSN to theSource RAN. The transparent container with its configuration options isforwarded to mobile station (MS) 30 in the handover command messagedepicted as event 6-9 in FIG. 6. In response to the relocation commandof event 6-8, a relocation commit message is sent from the Source RAN tothe target RAN as event 6-10.

[0073] As events 6-11 through 6-13, a SRNS context is transferred fromthe Source RAN to the target RAN. The SRNS context is specificallytransferred from the Source RAN to the old SGSN as event 6-11; from theold SGSN to the new SGSN as event 6-12; and from the new SGSN to thetarget RAN as event 6-13, of packets from the Source RAN to the targetRAN is depicted as event 6-14.

[0074] As in the first mode of the invention, in the second mode mobilestation (MS) 30 decides which header adaptation strategy is to beemployed. Such decision or election is depicted as event 6-15 in FIG. 6.Access bursts are made in event 6-16 to establish a physical layerconnection in the target cell.

[0075] Event 6-17 depicts the target RAN detecting a signal from themobile station (MS) 30. The detection can be registered at a RNC node ora BSC node of the target RAN, depending on the particular radio accessnetwork classification. When the target RAN detects signals from mobilestation (MS) 30, the target RAN sends a relocation detect message asevent 6-18 to the new SGSN. The core network then switches the userplane from the Source RAN to the target RAN. The GGSN then updates itsPDP context accordingly, as reflected by the update PDP context requestmessage of event 6-19 and the update PDP context report message of event6-20.

[0076] When mobile station (MS) 30 has reconfigured itself (e.g., at thephysical layer), mobile station (MS) 30 sends the handover completemessage of event 6-21 to the target RAN. The handover complete messageof event 6-21 includes the election of header adaptation strategy asmade at event 6-15. Optionally, the handover complete message caninclude an indication of the codec which is being used in the case ofoptimized voice.

[0077] An exchange of packets with mobile station (MS) 30 can nowcommence. The target RAN then, as event 6-22, sends a relocationcomplete message to the new SGSN, when forwards the indication in aforward relocation complete message (event 6-23) to the old SGSN. Theold SGSN then authorizes the Source RAN to release radio resourcesutilized over the Iu interface (event 6-24), the completion of which isconfirmed in a Iu release complete message (event 6-25).

[0078] Thus, the present invention also pertains to the radio accessnetwork which implements the mobile station-elected header adaptationcapability of the present invention, as well as nodes of such networkswhich cater to such capability and mobile terminals which make andcommunicate such election. Moreover, in one of its aspects describedabove, the present invention concerns one or more of the preparation,format, transmission, decoding, and use of the messages which downloadthe configuration options and the return message which apprises the RANof the mobile-elected header handling strategy.

[0079] The invention provides a RAN-independent solution, with minimalsignaling and overhead, to the problem of electing between headercompression and header removal. Otherwise, dedicated procedures wouldhave to be developed for the non-access stratum and core networkfunctions, and modification would be necessary for the entire call setupprocess.

[0080] While the invention has been described in connection with what ispresently considered to be the most practical and preferred embodiment,it is to be understood that the invention is not to be limited to thedisclosed embodiment, but on the contrary, is intended to cover variousmodifications and equivalent arrangements included within the spirit andscope of the appended claims. TABLE 1 RADIO BEARER SETUP MESSAGEInformation Element/Group Type and name Need Multi reference Semanticsdescription Message Type M Message Type MS Information Elements RRCtransaction identifier M RRC transaction identifier Integrity check infoC Integrity IE shall be set to the used check info signalling radiobearer identity when the encoded RRC message is used as the MESSAGEparameter in the integrity protection algorithm Integrity protectionmode info O Integrity At least 2 spare values, protection Criticality:reject, are needed mode info The IE is mandatory if the IE “Integrityprotection mode command”has the value “start”, otherwise it is notneeded in the message. The IE is only present if the IE “Integrityprotection mode command”has the value “modify” Ciphering mode info OCiphering This information element mode info contains the cipheringspecific security mode control information. 14 spare values needed.Criticality: criticality reject is needed. Starting time M 44.18- [Note:replaces the Activation 10.5.2.38 Time that is used in UTRAN.] Startingtime procedures New G-RNTI O G-RNTI The G-RNTI (GERAN Radio NetworkTemporary Identity) is allocated to an MS having a RRC connection andidentifies the MS within GERAN RRC state identifier M 43.051 The elementshows the possible states in case of lu mode CN Information Elements CNInformation info O CN Identifies the type of core Information networkdomain. Enumerated info CS domain, PS domain GERAN mobility informationelements GRA identity GRA identity Gives the identity of the GERANRegistration Area RB Information Elements Signalling RB information to 1to For each signalling radio setup list [Note: SRBs are FFS <maxSRBbearer established in GERAN] setup> Signalling RB information to M setupRAB information to setup list O 1 to For each RAB established <maxRABsetup> RAB information for setup M RB information to be affected list O1 to RB information affected are <maxRB> RB mapping info and RBidentity. RB information to be affected M RB with PDCP information listO 1 to This IE is needed for each RB <maxRBall having PDCP in the caseof RABs> lossless SRNS relocation RB with PDCP information M RB withPDCP information Quality target parameters FFS [Note: QoS parameters areFFS] PhyCH information elements Common paramters for TCH and PDTCH TN MChannel The TN field (3 bit) is the description binary representation ofthe 10.5.2.5- timeslot number as defined in 44.018 [FFS] GSM 05.10.Range: 0 to 7 ARFCN M Channel The ARFCN field (10 bit) is thedescription binary representation of the 10.5.2.5- absolute RF channelnumber, 44.018 [FFS] see 3GPP TS 45.005. Range: 0 to 63 MAIO M ChannelThe MAIO field (6 bit) is the description binary representation of the10.5.2.5- mobile allocation index offset, 44.018 [FFS] see 3GPP TS45.002. Range: 0 to 63. CHOISE logical channel type TCH parameters Cchannel type Channel Channel type field is 5 bits description (number ofbits needed is 10.5.2.5- FFS) 44.018 [FFS Range: 0 to 63 TSC Channel TheTSC field (3 bit) is the description binary representation of the10.5.2.5- training sequence code as 44.018 [FFS] defined in 3GPP TS45.002 lndirect encoding of hopping RF channel configurationMA_NUMBER_IND Channel The MA_NUMBER_IND field description (1 bit) is thebinary 10.5.2.5- representation of the 44.018 [FFS]MA_(—NUMBER to use as) reference to a GPRS mobile allocationCHANGE_MARK_1 Channel The CHANGE_MARK_1 field description (2 bit) is thebinary 10.5.2.5- representation of the allowed 44018 [FFS] value of theSI change mark associated with the GPRS mobile allocation to which theMA_NUMBER refers. Range: 0 to 3. Direct encoding of hopping RF channelconfiguration MAIO: bit (6)> Channel The MAIO field (6 bit) is thedescription binary representation of the 10.5.2.5- mobile allocationindex offset, 44.018 [FFS] see 3GPP TS 45.002. Range: 0 to 63. HSNChannel The HSN field (6 bit) is the description binary representationof the 10.5.2.5- hopping sequence number, 44.018 [FFS] see 3GPP TS45.002. Range: 0 to 63. Fast_power_control C Boolean Fast power controlparameter Stage2- which takes two values on or 43.051 off. Coding schemeEnumerated Modulation schemes used for (,) RB:43.051 Annex A PDTCHparameters C MEASUREMENT_INTER- If present, this field is encoded VAL (5bit field) as the MEASUREMENT_INTERVAL field in the PACKET DOWNLINKASSIGNMENT message in GSM 04.60. This information field indicates thenumber of block periods from start of the one assigned measurementperiod to the beginning of the next measurement period.LINK_QUALITY_MEASURE- THis field in encoded as the MENT_MODE (2 bitfield) LINK_QUALITY_MEASURE- MENT_MODE in the PACKET DOWNLINK ASSIGNMENTmessage in GSM 04.60. This field determines the measurements to beincluded within the EGPRS Timeslot Link Quality Measurements IE PDTCHrate C Enumerated 43.051-Annex. A (full,half)

[0081] TABLE 2 RAB INFORMATION FOR SETUP Information Element/Group Typeand name Need Multi reference Semantics description RAB info MP RAB info10.3.4.8 RB information to setup list MP 1 to <maxRBper RAB> RBinformation to setup MP RB information to setup 10.3.4.20

[0082] TABLE 3 RB INFORMATION TO SETUP Information Element/Group Typeand name Need Multi reference Semantics description RB identity MP RBidentity 10.3.4.16 PDCP info OP PDCP info 10.3.4.2 CHOICE RLC info typeMP RLC info RLC info 10.3.4.23 Same as RB RB identity Identity of RBwith exactly the 10.3.4.16 same RLC info IE values RB mapping info MP RBmapping info 10.3.4.21

[0083] TABLE 4 PDCP INFO Information Element/Group Type and name NeedMulti reference Semantics description Support for lossless SRNS CV-Boolean TRUE means support relocation Lossless Criteria Max PDCP SNwindow CV Integer (255, Maximum PDCP sequence size Lossless 65535)number window size. The handling of sequence number when the Max PDCP SNwindow size is 255 is specified in [23]. Default value is 65535. PDCPPDU header MD Enumerated Whether a PDCP PDU header (present, is existentor not. Default value absent is “present” Header Adaption OP 1 toIndicates whether header information <maxPDC adaptation algorithms canbe PAlgoType offered by the RAN. Header Removal supported OP Indicatesif Header Removal is supported or not. Header Removal specific MD AnyHeader Removal specific parameters parameters, such as RTP informationRFC3095 supported OP Header compression according to IETF standardRFC3095 Max_CID MD Integer Highest context ID number to (1.. be used bythe compressor. 16383 Default value is 15. Profiles MP 1 to Profilessupported by the <maxR decompressor. OHC- Profiles> Profile instance MPInteger( 1 Supported profile types. At 3 least four spare values. MRRUMD Integer Maximum reconstructed (0.. reception unit. Default 65535)value is 0 (no segmentation). Packet_Sizes_Allowed Op 1 to List ofpacket sizes that are <maxR allowed to be produced by OHC- RFC 3095.Packet Sizes> Packet size MP Integer Packet size as defined in (2..RFC3095. 1500 Reverse_Decompression MD Integer Determines whether Depth(0..65535) reverse decompression should be used or not and the maximumnumber of packets that can be reverse decompressed by the decompressor.Default value is 0 (reverse decompression shall not be used.

[0084] TABLE 5 RADIO BEARER SETUP COMPLETE Information Element/GroupType and name Need Multi reference Semantics description Message Type MMessage Type MS information elements RRC transaction identifier M RRCtransaction identifier Integrity check info C Integrity IE shall be setto the used check info signalling radio bearer identity when the encodedRRC message is used as the MESSAGE parameter in the integrity protectionalgorithm Uplink integrity protection O Integrity This IE contains thetime, in activation info protection terms of RRC sequence activationnumbers, when a new integrity info protection configuration shall beactivated for the signalling radio bearers RB Information elementsHeader Adaptation info M Specifies which header adaptation algorithm theMS chose for the RB. Header Removal OP If this IE is included then RFC3095 supported cannot be included. Codec negotiated M EnumeratedIndicates which codec was (HR, FR, negotiatated by SIP for this EFR,AMR) radio bearer. 4 spare values. Header Removal specific M Here, thesource and parameters destination P address could be included, as wellas UDP port number if not conveyed to the RAN by another method. RFC3095 OP If this IE is included then Header Removal supported cannot beincluded. COUNT-C activation time-FES O Activation Used for radio timebearers mapped on RLC-TM. Only applicable if the UE is moving toCELL_DCH state due to this procedure Radio bearer uplink ciphering RBThis IE contains the time, in activation time info activation terms ofRLC sequence time info numbers, when a certain configuration shall beactivated, for a number of radio bearers Uplink counter synchronisationO info (FFS) RB with PDCP information list O 1 to This IE is needed foreach RB <maxRBall having PDCP in the case of RABs> lossless SRNSrelocation RB with PDCP information M RB with PDCP information STARTlist M 1 to START [40]values for all ON <maxCN domains. domains> CNdomain identity M CN domain identity

[0085] TABLE 6 RRC CONNECTION SETUP COMPLETE Information Element/GroupType and name Need Multi reference Semantics description Message Type MPMessage Type UE Information Elements RRC transaction identifier MP RRCtransaction identifier 10.3.3.36 START list MP 1 to START [40]values forall CN <maxCNdo domains. mains> CN domain identity MP CN domain identity10.3.1.1 START MP START START value to be used in 10.3.3.38 this CNdomain. UE radio access capability OP UE radio access capability10.3.3.42 Other information elements UE system specific capability OP 1to <maxSystem Capability> lnter-RAT UE radio access MP Inter-RATcapability UE radio access capability 10.3.8.7

[0086] TABLE 7 UE radio access capability Information Element/Group Typeand name Need Multi reference Semantics description lCS version MPEnumerated Indicates the release version (R99) of [42]-2 (ImplementationConformance Statement (lCS) proforma specification) that is applicablefor the UE. PDCP capability MP PDCP capability 10.3.324 RLC capabilityMP RLC capability 10.3.3.34 Transport channel capability MP Transportchannel capability 10.3.3.40 RE capability MP RF capability 10.3.3.33Physical channel capability MP Physical channel capability 10.3.3.25 UEmulti-mode/multi-RAT MP UE multi- capability mode/multi- RAT capability10.3.3.41 Security capability MP Security capability 10.3.3.37 UEpositioning capability MP UE positioning capability 10.3.3.45Measurement capability CH- Measurement fd_req_sup capability 10.3.3.21Condition Explanation fdd_req_sup Presence is mandatory if IE Multi-modecapability has the value “FDD” or “FDD/TDD” and a FDD capability updatehas been requested in a previous message. Otherwise this field is notneeded in the message.

[0087] TABLE 8 PDCP capability Information Element/Group Type and nameNeed Multi reference Semantics description Support for lossless SRNS MPBoolean TRUE means supported relocation Support for Header Removal MPBoolean TRUE means supported Support for RFC3095 MP Boolean TRUE meanssupported

What is claimed is:
 1. For use in a radio access network which supportsradio communication with a mobile station (MS), a method comprising: (1)sending from the radio network access network to the mobile station (MS)a message that downloads configuration options for each of plural headeradaptation strategies for Internet-transmissible packets; (2) receivingat the radio access network a message which informs the radio accessnetwork which of the plural strategies is elected by the mobile station(MS).
 2. The method of claim 1, wherein the message of step (1) and themessage of step (2) are radio resource control (RRC) messages.
 3. Themethod of claim 2, wherein the message of step (1) is a radio bearersetup message and the message of step (2) is a radio bearer setupcomplete message.
 4. The method of claim 1, wherein the plural headeradaptation strategies includes header compression.
 5. The method ofclaim 4, wherein the header compression strategy is for a multimediaservice.
 6. The method of claim 1, wherein the plural header adaptationstrategies includes header removal.
 7. The method of claim 6, whereinthe header removal strategy is for a spectrum efficient voice packetvoice bearer that reuses codec-specific channel coding.
 8. The method ofclaim 1, wherein the radio access network is a GSM/EDGE radio accessnetwork.
 9. The method of claim 1, wherein the message of step (1) ishandover command message for handing over control of the mobile stationfrom a source radio access network to a target radio access network, andthe message of step (2) is handover complete message.
 10. The method ofclaim 9, further comprising: generating, at a target radio accessnetwork, the configuration options for each of the plural headeradaptation strategies; sending the configuration options from the targetradio access network to a source radio access network; and sending theconfiguration options from the source radio access network to the mobilestation.
 11. The method of claim 10, wherein one of the target radioaccess network and the source radio access network is a GSM/EDGE (GERAN)radio access network and another of the target radio access network andthe source radio access network is a UTRAN (Universal MobileTelecommunications radio access network).
 12. The method of claim 1,wherein the Internet-transmissible packets are speech or voice packetshaving a RTP/UDP/IP header.
 13. A radio access network which supportsradio communication with a mobile station (MS), the radio access networkcomprising a network node which (1) sends to the mobile station (MS) amessage that downloads configuration options for each of plural headeradaptation strategies for Internet-transmissible packets and which (2)receives a message from the mobile station (MS) which informs the radioaccess network which of the plural strategies is elected by the mobilestation (MS).
 14. The apparatus of claim 13, wherein the message sentfrom the radio access network node to the mobile station (MS) and themessage received at the radio access network from the mobile station(MS) are radio resource control (RRC) messages.
 15. The apparatus ofclaim 13, wherein the message sent from the radio access network node tothe mobile station (MS) is a radio bearer setup message and the messagereceived at the radio access network from the mobile station (MS) is aradio bearer setup complete message.
 16. The apparatus of claim 13,wherein the plural header adaptation strategies includes headercompression.
 17. The apparatus of claim 16, wherein the headercompression strategy is for a multimedia service.
 18. The apparatus ofclaim 13, wherein the plural header adaptation strategies includesheader removal.
 19. The apparatus of claim 18, wherein the headerremoval strategy is for a spectrum efficient voice packet voice bearerthat reuses codec-specific channel coding.
 20. The apparatus of claim13, wherein the radio access network is a GSM/EDGE radio access network.21. The apparatus of claim 13, wherein the radio access network node isa base station controller (BSC) node.
 22. The apparatus of claim 13,wherein the network node is a node of one of a target radio accessnetwork and a source radio access network, and wherein the message thatdownloads configuration options for each of plural header adaptationstrategies is a handover command message for handing over control of themobile station from the source radio access network to the target radioaccess network and the message which informs which of the pluralstrategies is elected is a handover complete message.
 23. The apparatusof claim 22, wherein the target radio access network generates theconfiguration options for each of the plural header adaptationstrategies and sends the configuration options from the target radioaccess network to a source radio access network; and wherein the sourceradio access network sends the configuration options from the sourceradio access network to the mobile station.
 24. The apparatus of claim23, wherein one of the target radio access network and the source radioaccess network is a GSM/EDGE (GERAN) radio access network and another ofthe target radio access network and the source radio access network is aUTRAN (Universal Mobile Telecommunications radio access network). 25.The apparatus of claim 13, wherein the Internet-transmissible packetsare speech or voice packets having a RTP/UDP/IP header.
 26. A mobilestation (MS) which is in radio communication with a radio accessnetwork, the mobile station (MS) comprising: a transceiver unit whichreceives a downloading message from the radio access network and sends areturn message to the radio access network, the downloading messageincluding configuration options for each of plural forInternet-transmissible packets header adaptation strategies; a unitwhich elects one of the plural header adaptation strategies and includesthe elected strategy in a return message.
 27. The apparatus of claim 26,wherein the downloading message and the return message are radioresource control (RRC) messages.
 28. The apparatus of claim 27, whereinthe downloading message is a radio bearer setup message and the returnmessage is a radio bearer setup complete message.
 29. The apparatus ofclaim 26, wherein the plural header adaptation strategies includesheader compression.
 30. The apparatus of claim 29, wherein the headercompression strategy is for a multimedia service.
 31. The apparatus ofclaim 26, wherein the plural header adaptation strategies includesheader removal.
 32. The apparatus of claim 31, wherein the headerremoval strategy is for a spectrum efficient voice packet voice bearerthat reuses codec-specific channel coding.
 33. The apparatus of claim26, wherein the radio access network is a GSM/EDGE radio access network.34. The apparatus of claim 26, wherein the message that downloadsconfiguration options for each of plural header adaptation strategies isa handover command message for handling over control of the mobilestation from a source radio access network to a target radio accessnetwork and the message which informs which of the plural strategies iselected is a handover complete message.
 35. The apparatus of claim 34,wherein one of the target radio access network and the source radioaccess network is a GSM/EDGE (GERAN) radio access network and another ofthe target radio access network and the source radio access network is aUTRAN (Universal Mobile Telecommunications radio access network). 36.The apparatus of claim 26, wherein the Internet-transmissible packetsare speech or voice packets having a RTP/UDP/IP header.